+section('Examples')
  +subsection('Basic form')
    p.typo__p
      | For each value you want to validate, you have to create a key inside <kbd>validations</kbd> options.
      | You can specify when input becomes dirty by using appropriate event on your input box.
    p.typo__p
      | Note that in this example, the red border, red text, and error message visibility are driven by the presence or absence of the <kbd>form-group--error</kbd> class on the surrounding <kbd>div</kbd>. 
      | Any markup relating to validation errors will show on initial load unless using a method like this, or by using validations without v-model (next section).
    +example('ExampleBasic')

  +subsection('Without v-model')
    p.typo__p
      | In case you don't want to modify your model directly,
      | you can still use separate <kbd>:input</kbd> and <kbd>@event</kbd> bindings.
      | This is especially useful if you are using data from external source, like Vuex store or props.
      | In that case you have to manually take care of setting the <kbd>$dirty</kbd>
      | by calling <kbd>$touch()</kbd> method when appropriate.
    +example('ExampleEvent')

  +subsection('Form submission')
    p.typo__p
      | A common thing to do with validated forms is to check their validity before submission. You can accomplish this
      | easily by checking for <kbd>$invalid</kbd> state before sending any requests.
    +example('ExampleSubmit')

  +subsection('Contextified validators')
    p.typo__p
      | You can link related fields by contextified validators. An example of this being <kbd>sameAs</kbd> builtin validator.
    +example('ExampleRepeatPassword')

  +subsection('Data nesting')
    p.typo__p
      | You can nest validators to match your data as deep as you want.
      | Parent validator is <kbd>$invalid</kbd> when any of its children validators reports an <kbd>$invalid</kbd> state.
      | This might be very useful for overall form validation.
    +example('ExampleNested')

  +subsection('$error vs $anyError')
    p.typo__p
      | There are two common ways of considering if an error should be displayed. It is important to understand which one
      | suits your use case better. You can use either <kbd>$error</kbd> or <kbd>$anyError</kbd> validation property,
      | or by extension, the low-level variants: <kbd>$dirty</kbd> or <kbd>$anyDirty</kbd>.
      | Note that this documentation uses mainly <kbd>$error</kbd> variant in it's examples, but the choice is yours to make.

    +example('ExampleAnyDirty')

  +subsection('Validation Groups')
    p.typo__p
      | If you want to create a validator that groups many otherwise unrelated
      | fields together, you can create a validation group.
    +example('ExampleValidationGroups')

  +subsection('Collections validation')
    p.typo__p
      | Array support with <kbd>$each</kbd> keyword
    +example('ExampleEachArray')

  +subsection('Asynchronous validation')
    p.typo__p
      | Async support is provided out of the box. Just use a validator that returns a promise.
      | Promise's success value is used for validation directly,
      | failed promise just fails the validation and throws the error.
    p.typo__p
      | Any component's data has to be accessed synchronously for correct reactive
      | behaviour. Store it as a variable in validator's scope
      | if you need to use it in any asynchronous callback, for example in <kbd>.then</kbd>.
    p.typo__p
      | Validator is evaluated on every data change, as it is essentially a computed value.
      | If you need to throttle an async call, do it on your data change event,
      | not on the validator itself. You may end up with broken Vue observables otherwise.

    +example('ExampleAsync')
    p.typo__p
      | The <kbd>async</kbd>/<kbd>await</kbd> syntax is fully supported. It works especially great in combination with Fetch API.
    div
      pre(v-pre).language-javascript
        code.
          validations: {
            async isUnique (value) {
              if (value === '') return true
              const response = await fetch(`/api/unique/${value}`)
              return Boolean(await response.json())
            }
          }

  +subsection('Delayed validation errors')
    p.typo__p
      | You can do anything you need with the $touch state, no matter how fancy your requirements are.
      | It all boils down to calling $touch and $reset in the right moment. As an example of that,
      | here is an easy to follow implementation of delayed error based on custom <kbd>setTimeout</kbd> logic.
      | It triggers one second after last input.
    +example('ExampleDelayedTouch')

  +subsection('Accessing validator parameters')
    p.typo__p
      | You can access information about your validations through `$params` of a parent validator.
      | This is be useful for reporting errors to users.
    +example('ExampleParams')

  +subsection('Dynamic validation schema')
    p.typo__p
      | Validations schema can be a function, which will make it dynamic and possibly
      | dependant on your model's data. Recomputations will happend automatically as if
      | it was a computed value. Validation's <kbd>$dirty</kbd> state will be preserved
      | as long as the key name won't change or disappear.
    +example('ExampleDynamic')

  +subsection('Dynamic parameters')
    p.typo__p
      | Because the whole validation process is based on computed properties,
      | nothing prevents you from making the validator name dynamic.
      | Such cases allows for very dynamic behaviour even when your data is changing in time.
    +example('ExampleDynParams')
